Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungswesens (GeoInfoDok) - Gesamtkonzept

Internationale Normungs- bzw. Standardisierungsaktivitäten im Bereich von Geoinformationen erfolgen zurzeit in folgenden Gremien:

Ziel ist die Schaffung von Grundlagen für die gemeinsame, ganzheitliche und fachübergreifende Nutzung von Geodaten an verschiedenen Orten durch Personen, Anwendungen und Systeme auf der Grundlage einer einheitlichen Beschreibung der Inhalte vorhandener oder geplanter Datenbestände, der Funktionalitäten der Datenbearbeitung und der Kommunikation. Der Modellierung liegen die Ergebnisse des ISO/TC 211 in Form der Normfamilie 19100 im aktuellen Bearbeitungsstand zu Grunde. Im Bereich der Datenaustauschschnittstelle werden darüber hinaus auch Teile der Spezifikationen des OGC verwendet. Für die Integration von 3D-Informationen bildet CityGML (OGC Best Practices Document in der Version 0.4.0) die Grundlage.

Zur Beschreibung des Anwendungsschemas und der Objektartenkataloge hat sich die AdV entschieden, die Datenmodellierungssprache Unified Modeling Language (UML) zu verwenden. Sie wird auch von ISO/TC 211 im Bereich der Normung von Geoinformationen eingesetzt.

UML wurde von der Object Management Group (OMG) zur Beschreibung von Anwendungsschemata entwickelt. Semantik und Notation von UML sind im UML Notation Guide beschrieben. Um eine einheitliche Nutzung von UML im Bereich der Normfamilie 19100 zu gewährleisten, ist deren Anwendung in der ISO-Spezifikation 19103 Conceptual schema language festgelegt. Der Zweck liegt in der vollständigen und unzweifelhaft interpretierbaren, formalen Beschreibung von Inhalt und Struktur von Datenbeständen. Die Beschreibung ist unabhängig von der Art der Implementierung und der verwendeten Programmiersprache. Mit formalen Sprachen ist eine einheitliche Beschreibung aller Geodaten erreichbar. Die so beschriebenen Anwendungsschemata können von geeigneten Programmen automatisch interpretiert und in interne Datenstrukturen bzw. Datenbankstrukturen übersetzt werden.

Ein universelles und systemunabhängiges Datenaustausch- bzw. Dateiformat ergibt sich daraus automatisch in Verbindung mit sogenannten Kodierungsregeln. Diese Kodierungsregeln werden entsprechend der ISO-Normen 19118 Encoding und 19136 Geography Markup Language (GML) erstellt. Als Format wird die Auszeichnungssprache XML (Extensible Markup Language) des World-Wide-Web Consortiums (W3C) verwendet.

Die Regeln zur Erstellung von Anwendungsschemata werden durch die Norm 19109 "Rules for Application Schema" des ISO/TC 211 vorgegeben. In dieser Norm ist auch das allgemeine Modell zu Beschreibung und Bildung von Fachobjekten (General Feature Model) enthalten. Das gemeinsame Basisschema wird an das General Feature Model von ISO 19100 angeschlossen und dieses um die Metaklasse "AA_ObjektOhneRaumbezug" erweitert, um Objektklassen bilden zu können, für die kein Raumbezug zulässig ist.

Die Bildung eigenständiger Objekte ergibt sich aus der fachlichen Objektsicht. Objekte mit geometrischer Ausprägung können punkt-, linien-, flächen- und volumenförmige Beschreibungen führen oder vom Typ Punktmengenobjekt sein. Objekte ohne Raumbezug (z. B. Personen) tragen keine Geometrie und lassen sich nicht auf einen bestimmten Ort festlegen. Sie können aber mit anderen raumbezogenen und nicht-raumbezogenen Objekten in Beziehung stehen, z. B. mit Flurstücken, Gebäuden oder Adressen.

Zur Systematisierung und zur Unterstützung bei der Erstellung der Fachschemata werden im gemeinsamen AAA-Basisschema folgende Arten von Objektausprägungen vordefiniert:

Elementarobjekte sind die kleinste mögliche fachliche Einheit. Die Bildung von Objektteilen oder von Linien als Objektbestandteile mit fachlicher Information wie in den bisherigen Systemen ALK und ATKIS entfällt.

Die Führung der Historie von Objekten wird unterstützt. Ebenso werden Integrations- und Verknüpfungsmöglichkeiten der Fachobjekte mit den Fachdaten anderer Fachbereiche unterstützt.

Alle instanziierbaren fachlichen Objektklassen sind in den anwendungsbezogenen Subschemata aus den folgenden Objektklassen des Basisschemas durch Vererbung abzuleiten:

Für Präsentationsobjekte können folgende Objektklassen des Basisschemas direkt verwendet bzw. instanziiert werden:

Alternativ ist zugelassen, dass aus diesen Objektklassen des Basisschemas durch Vererbung weitere instanziierbare fachliche Objektklassen abgeleitet werden.

Die in den Fachschemata zu beschreibenden Objekte können selbstbezogene Eigenschaften (Attribute) besitzen. Attribute sind die Träger der statischen Informationen der Objekte. Attribute werden immer über einen Namen und eine Werteart definiert. Wertearten können sowohl Basisdatentypen (Zahlen, Zeichenketten, Datums- und Zeitangaben) als auch komplexe Datentypen wie Geometrien oder Qualitätsmerkmale sein. Attribute können grundsätzlich multipel und Zeichenketten beliebig lang sein.

Attribute vom Typ Datums- und/oder Zeitangabe ("DateTime") werden entsprechend den Festlegungen von ISO 8601, Kapitel 5.4.1 in Verbindung mit 5.3.3 modelliert. Hierbei wird die Variante mit Trennzeichen gewählt. Zeitgenauigkeit ist die volle Sekunde, Zeitzone ist immer UTC (Universal Time Coordinated, Greenwich Mean Time, Abkürzung: Z). Beispiel: 2004-02-29T10:15:30Z

Die in den Fachschemata zu beschreibenden Objekte können fremdbezogene Eigenschaften (Beziehungen bzw. Relationen) besitzen. In den Fachschemata können verschiedene Arten von Beziehungen verwendet werden:

Die Präsentationsobjekte sind wegen den allgemeingültigen Eigenschaften im AAA Basisschema beschrieben.

Die Präsentationsobjekte enthalten eine Signaturnummer und weitere Eigenschaften zur Steuerung der Präsentation, wie z. B. Darstellungspriorität und Art. Präsentationsobjekte müssen in ALKIS mit den entsprechenden Fachobjekten durch eine Relation "dientZurDarstellungVon" verbunden sein. In ATKIS gibt es keine derartige Regel, d.h. es dürfen "freie Präsentationsobjekte" existieren. Die Präsentation von Objekten in graphischen sowie nicht graphischen Ausgaben erfolgt gemäß nachstehender Abbildung in folgender Weise:

Präsentation in der Karte

Präsentation der Liegenschaftsbeschreibung

Die Präsentation der Angaben für eine Liegenschaftsbeschreibung, wie z. B. Flurstücks- und Eigentümernachweis, erfolgt ausschließlich zur Laufzeit über die Anwendung des Filter Encodings und der Regeln, die im AAA-Ausgabekatalog hinterlegt sind. Diese Ausgabedaten werden in Verbindung mit einer konkreten Ableitungsregel aus dem nicht formalisierten Signaturenkatalog präsentiert. Die jeweiligen Textpositionen können dem entsprechenden Standbogen entnommen werden. Muster für die Produktausgabe sind ein zusätzlicher Anhalt.

Erzeugung der Präsentationsobjekte und AP_Darstellung für den Bestand

Um eine effiziente Präsentation der Fachobjekte in einer Ausgabe zu gewährleisten, müssen bereits zum Zeitpunkt der Erhebung / Fortführung geeignete Präsentationsvorgaben festgelegt werden. Es werden dabei, gemäß Abbildung 19 drei Fälle unterschieden:

Präsentationsobjekte 3D

Das Paket AAA_Praesentationsobjekte_3D konkretisiert die Fachobjekte von AAA_Unabhaengige Geometrie 3D für die Zwecke der Präsentation. Die entsprechenden Fachobjekte können unmittelbar instanziiert werden.

Das 3D Präsentationsobjekt AP_KPO_3D wird für 3D Symbole verwendet, deren 3D Geometrie in einem externen Datenformat gespeichert wird und über eine URI referenziert wird. AP_KPO_3D leitet sich aus AU_Punktobjekt_3D ab und seine 3D Punktgeometrie positioniert das Symbol. Über eine Transformationsmatrix wird die lageunabhängige 3D Geometrie in dem externen Datenformat in den Raumbezug des Präsentationsobjektes AP_KPO_3D transformiert. Die Präsentationsobjekte sind wie andere Objekte im Objektartenkatalog in Verbindung mit dem jeweiligen Signaturenkatalog bzw. 3D Symbolbibliotheken zu definieren.

Regelung von länderübergreifend redundanzfreier Vergabe länderspezifischer Signaturnummern

Das AFIS-ALKIS-ATKIS-Datenmodell bringt den Anwendern neben vielen anderen Vorteilen eine länderübergreifende Vereinheitlichung der Datenbestände sowie deren Präsentation.

Der Bedarf an frei gestaltbaren Ausgaben seitens der Länder besteht. Dies belegen mehrere landespezifische Signaturenkataloge. Bei deren Schaffung wurden unterschiedliche Wege beschritten, exemplarisch hier anhand zweier Bundesländer aufgezeigt:

Baden-Württemberg hat als einziges Bundesland im ALKIS-Signaturenkatalog der AdV länderspezifische Anteile mit eigenen Signaturnummern unterbringen können. Eine Erweiterung um länderspezifische Anteile weiterer Länder ist von der AdV nicht beabsichtigt, da sie für die Pflege länderspezifischer Vorgaben nicht zuständig ist.

Nordrhein-Westfalen hat einen eigenen ALKIS-Signaturenkatalog geschaffen, dessen Inhalte unabhängig neben dem der AdV veröffentlicht werden.

Folgende Regelung gewährleistet die Redundanzfreiheit der Signaturnummern bei länderspezifischen Erweiterungen des ALKIS-Signaturenkataloges. Damit wird vermieden, dass länderübergreifende Datennutzer zukünftig möglicherweise mit identischen Signaturnummern verschiedener Länder konfrontiert werden, die inhaltlich unterschiedliche Präsentationen bewirken sollen. Es gelten folgende Vorgaben:

Als Kartengeometrieobjekte werden diejenigen Fachobjekte definiert, die bei der Ableitung für einen bestimmten Kartenmaßstab aus Gründen der kartographischen Generalisierung ihre geometrische Form und / oder Lage verändert haben. Ein Kartengeometrieobjekt muss folgende eigenständige Informationen enthalten: Den Identifikator, die Angabe des Kartenmodells, z. B. DTK10, zu dem es gehört, die einseitige Relation ist_abgeleitet_aus auf das zugrundeliegende AFIS-ALKIS-ATKIS-Objekt sowie die eigentliche Geometrie. Darüber hinaus muss es die Attribute des zugrundeliegenden AFIS-ALKIS-ATKIS-Objekts enthalten, um in den Ableitungsregeln des Signaturenkatalogs für die Präsentation ausgewertet werden zu können.

Als Punktmengenobjekte (PMO) werden Fachobjekte dann definiert, wenn einer großen Anzahl geometrischer Orte Attributwerte jeweils gleicher Attributarten zugeordnet werden soll. Dies ist im AAA-Anwendungskontext insbesondere bei Digitalen Geländemodellen, die i.d.R. Höheninformationen in einer Gitterstruktur vorhalten, der Fall. Da aber auch häufig unregelmäßig verteilte, gleichartige Informationen vorgehalten werden sollen, z.B. Höhenmesspunkte, wurde außer der Gittervariante der PMO (AD_GitterCoverage) auch eine Variante für eine beliebige Punktverteilung zugelassen (AD_PunktCoverage). Die Modellierung realisiert die Klassen aus ISO 19123 Coverages. Sie wird in der Weise eingeschränkt, dass für die Sequenz der Attributwerte (CV_SequenceType) nur "linear" zulässig ist.

In allen AAA-Objekten kann im Attribut 'zeigtAufExternes' eine Fachdatenverbindung untergebracht werden. Die Modellierung lässt dies auf zwei Arten zu, nämlich in Form der URN- oder der URL-Variante. Im Modell steht hierzu beim Attribut AA_Fachdatenverbindung.art folgendes:

Fachdatenverbindungen, die sich der URL-Variante bedienen, sind aufgrund der Eindeutigkeit der URNs unproblematisch.

Folgende Regelung gewährleistet die Redundanzfreiheit der Fachdatenverbindungen bei länderspezifischen Erweiterungen mit der URN-Variante. Dadurch wird vermieden, dass länderübergreifende Datennutzer zukünftig möglicherweise mit identischen Nummern von Fachdatenverbindungen verschiedener Länder konfrontiert werden, denen inhaltlich unterschiedliche Sachverhalte in Hintergrund stehen.

In Anlehnung an die in der GeoInfoDok übliche URN-Logik:

ist für Fachdatenverbindungen folgende URN zu verwenden:

Identifikatoren stehen stellvertretend für das Objekt, das sie repräsentieren. Daher bezeichnet man sie auch als Objektidentifikatoren oder kurz OID. Die wesentlichen Eigenschaften eines Identifikators sind:

Damit ist der Lebenszyklus von Identifikatoren identisch mit dem Lebenszyklus der Objekte, deren Repräsentanten sie sind. Die Frage, wann Identifikatoren geändert werden dürfen und wann nicht, darf somit nicht aus dv-technischer Sicht beantwortet werden, sondern es müssen fachliche Kriterien benannt werden,

So werden auch Objektidentifikatoren von Objekten, die von anderen Fachstellen im Rahmen ihrer Aufgaben erzeugt wurden, bei der Übernahme in die AAA-Datenhaltung unverändert übernommen. Auch bei Migration von Bestandsdaten in eine neue Version der GeoInfoDok beibt das ursprüngliche Lebenszeitintervall unverändert erhalten, mit Ausnahme der untergegangenen Elemente, welche lediglich aus Gründen der Abwärtskompatibilität noch im Modell belassen wurden, siehe entsprechendes Kapitel in den Release Notes TBD: Worauf genau in den Release Notes soll verwiesen werden?.

Für alle Fachobjekte wird eine eindeutige Bezeichnung als Objektidentifikator verwendet. Der Identifikator hat folgenden Aufbau:

Beispiele für Identifikatoren sind:
"DENW123412345678" (endgültiger Identifikator)
"DE_0000000000001" (vorläufiger Identifikator)

Zur Realisierung einer Geodateninfrastruktur im Sinne und unter Nutzung der Schnittstellendefinitionen des Open Geospatial Consortiums (OGC) müssen alle beteiligten Stellen eine Systematik für die Vergabe der Identifikatoren und ein Service-Interface definieren, sodass sichergestellt ist, dass Objekte über ihren Identifikator ohne weiteres Wissen gefunden werden können. Hier bietet sich im Sinne einer bundesweiten Lösung ein gemeinsamer Service und auch die Publikation von AAA-Bestandsdaten als Linked Open Data an; die Systematik der Vergabe und Verteilung kann unberührt davon länderspezifisch festgelegt werden.

Um Relationen zwischen den Fachobjekten im Datenaustausch aufzubauen, werden Identifikatoren auch als Referenzen auf Fachobjekte geführt.

Identifikatoren sind unter anderem auch erforderlich, um bei der Formulierung von Fortführungen angeben zu können, welche Objekte gelöscht und welche Objekte überschrieben werden sollen. Da die Objekte dabei in ihrer konkret vorliegenden Version angesprochen werden müssen, wird der o.a. Identifikator in diesen Fällen um die Angabe von Entstehungsdatum/-zeit der angesprochenen Objektversion ergänzt.

Eine wichtige Voraussetzung für die gemeinsame Führung von Datenbeständen unterschiedlicher Herkunft ist, dass die Integrationssituation in Form von Referenzen zwischen den Daten der Vermessungsverwaltung und den Fachdaten abgebildet ist (Verknüpfung). Diese Verknüpfung kann einseitig in den raumbezogenen Basisinformationssystemen der Vermessungsverwaltung oder im Fachinformationssystem (einseitige Verknüpfung) oder gegenseitig in beiden Informationssystemen (gegenseitige Verknüpfung) erfolgen. Als Verknüpfungsmerkmale sind eindeutige Bezeichnungen zu definieren und zu führen. Diese können aus den o.a. Identifikatoren und / oder aus Fachkennzeichen der jeweiligen Datenbestände bestehen.

Das AA_Objekt besitzt das Attribut modellart, welches eine Zuordnung zu einer oder mehreren Modellarten darstellt. Die erweiterbare Codelist "AA_WeitereModellart" erlaubt die Erfassung beliebiger, z.B. länderspezifischer Modellarten. Die Eintragung und Pflege solcher Wertearten und Bezeichner wird im Rahmen der AdV-Registry für Codelisten geregelt.

Die Enumeration AA_AdvStandardModell ist hingegen nicht erweiterbar und enthält die zulässigen Modellarten für die Anwendungsschemata der AdV. Durch die Angabe der Modellarten ist es möglich, sämtliche Elemente des Datenmodells (z.B. Objektarten, Attributarten etc.) einem oder mehreren Modellen zuzuordnen. Somit können trotz der einheitlichen und integrierten Modellierung unterschiedliche Fachsichten auf die Objekte der realen Welt abgebildet und in Form von fachspezifischen Objektartenkatalogen ausgegeben werden. Auswirkungen auf die NAS hat die Modellart jedoch nicht: Die NAS wird inhaltlich definiert durch das gesamte AAA-Anwendungsschema, wodurch auf der Ebene der Schnittstelle keine unterschiedlichen Fachsichten abgebildet werden können. Das bedeutet, es gibt nicht eine ATKIS- oder ALKIS-NAS, sondern nur die NAS.

Wird bei Objekt-, Attribut-, oder Wertearten keine Modellart angegeben, gibt es keine Einschränkungen bei der Verwendung von Modellarten, d.h. diese Elemente können für beliebige Modellarten verwendet werden. Umgekehrt bedeutet dies, dass bei der Angabe von Modellarten alle nicht erwähnten Modellarten asugeschlossen werden.

Der Level of Detail beschreibt die Detaillierungsstufe der 3D Geometrie eines raumbezogenen Elementarobjekts. Diese wird meistens durch die Erfassungs- bzw. Ableitungsmethode für die 3D Geometrie bestimmt. Es sollen nur die Level of Detail 1 bis 3 für ALKIS 3D verwendet werden. Die inverse Relationsrolle "detailliert" verweist auf das zugehörige raumbezogene Elementarobjekt mit einer 3D Geometrie in einer geringeren Detaillierungsstufe. Die Relationsrolle "generalisiert" verweist auf das zugehörige raumbezogene Elementarobjekt mit einer 3D Geometrie in einer höheren Detaillierungsstufe.

Die 3D-Ergänzung unterstützt verschiedene Levels of Detail (LoD). LoDs werden benötigt, um Gebäude und andere 3D-Objekte einem bestimmten Detailierungsgrad zuzuordnen. Ebenso dienen sie der effizienten Visualisierung und Datenanalyse.

Zur Definition der einzelnen LoD wurden folgende Dokumente herangezogen:

Der unterste Level LoD1 ist das Blockmodell, dort werden die Gebäude als einfacher Block mit Flachdach dargestellt. Der LoD2 stellt die unterschiedlichen Dachtypen dar, die Darstellung von Vegetation ist möglich. LoD3 ist der Level mit dem höchsten Detailierungsgrad. Dort werden detaillierte Wand- und Dachstrukturen, Vegetation und Straßenmöblierung abgebildet. Neben den visuellen Kriterien liegen den LoDs geometrische Mindestanforderungen zugrunde (siehe Tabelle 1):

In der Praxis wird es, in naher Zukunft, kein komplett texturiertes LoD geben. Aus diesem Grund bilden Texturierungen kein Kriterium für eine Einstufung in ein bestimmtes LoD und sind in allen LoD zugelassen.

Die Nutzung von Geometriebibliotheken ist eine Erweiterung der Möglichkeiten der Geometrieabbildung im 3D-Bereich. Geometriebibliotheken können zur Einbindung von Prototypen verwendet werden. Beispiele hierfür sind im 3D-Bereich Bäume, Ampeln, Laternen usw. Jede prototypische Geometrie existiert nur einmal in einem lokalen, kartesischen Koordinatensystem. Diese kann im Datenbestand mehrfach, mittels URI eines speziellen Präsentationsobjektes, referenziert werden. Die prototypische Geometrie kann ein lokaler File, ein remote-File sein oder durch einen Webservice geliefert werden. Die Art der referenzierten Geometrie wird attributiv beschrieben. Die korrekte Darstellung dieser Mimetypes muss von der Visualisierungssoftware sichergestellt werden. Zur Festlegung der Positionierung der prototypischen Geometrie im Datenbestand dient eine 3D-Transformationsmatrix. Sie beinhaltet die 16 Parameter für Rotation, Translation und Skalierung der lokalen Geometrie. Die Geometrie ist ein GM_MultiPoint, da so Objekte mit gleichen Eigenschaften mehrfach im Datenbestand gesetzt werden können.

Die Nutzung von Geometriebibliotheken hat einige Vorteile gegenüber der expliziten Repräsentation von Objekten mittels absoluten Koordinaten:

3D-Transformationsmatrix

Der Datentyp AP_TransformationsMatrix_3D repräsentiert eine allgemeine Transformationsmatrix in der Speicherform eines Vektors. Das Prinzip ist an Szenengraphenkonzepte angelehnt, wie sie im Bereich der Computergraphik gebräuchlich sind. Die Matrix enthält alle erforderlichen Parameter für die Transformation von homogenen Koordinaten aus beliebigen rechtwinkligen Koordinatensystemen der Prototypen in das Koordinatensystem des 3D-Modells.

Die nicht formalisierten Signaturenkataloge sind für die AdV-Produkte, die i.d.R. in der Ausgabe keinen Raumbezug nutzen, notwendig.

Hierzu zählen:

Die bisher verwendeten Teile A bis G sind in den jeweiligen Signaturenkatalog zusammengefasst. Ergänzt werden diese durch Standbögen (für die Darstellungen der Positionen auf dem jeweiligen Ausgabemedium) und Muster der Präsentationsausgaben für die AdV-Standardprodukte. Im Falle der Liegenschaftskarte werden die Karteninhalte mit Hilfe des formalisierten Signaturenkatalaog erzeugt.

Die Vorgaben zur Struktur eines Signaturenkatalogs (SK) haben übergeordneten Charakter und sind deshalb logisch getrennt zu sehen von der Beschreibung von fachlichen Objektarten in einem Datenmodell. Daher ist das Schema "AAA-Signaturenkatalog" außerhalb des AAA-Anwendungsschemas eigenständig modelliert.

Kern der Modellierung ist eine SK-Definitionssprache, Map-Definition-Language ("MDL", ursprünglich "SDL" genannt), welche alle SK-Definitionen in einer lesbaren, aber dennoch automatisiert verarbeitbaren Form darstellen kann. Ein zentrales MDL-Repository speichert den Stand des SKs in MDL und definiert damit die Referenzversion des SK.

Ein MDL-Compiler leitet aus dem in MDL definierten SK automatisch SK-Dokumente in HTML und PDF ab. Ein weiterer Output des MDL-Compilers ist eine Repräsentierung des SK in "SK-XML", einer XML-Sprache, die im Wesentlichen denselben Inhalt wie MDL bedient. Die Repräsentierung in SK-XML soll es ermöglichen, daraus einfach externe Repräsentierungen des SK zu generieren, um handelsübliche GIS-Software zu unterstützen. Die Umsetzungen aus SK-XML sollen durch externe Akteure erfolgen.

Da MDL und SK-XML naturgemäß strukturell verwandt sind, liegt es nahe, beide auf der Basis eines gemeinsamen, in UML definierten, Objektmodells zu entwickeln.

Im Rahmen der Zuständigkeit des amtlichen Vermessungswesens sind die Aufgaben Erhebung, Qualifizierung, Führung (Ersteinrichtung, Fortführung), Benutzung und Übertragung von Daten auszuführen. Jede dieser Aufgaben äußert sich in einem oder mehreren Prozessen. Es gibt Erhebungs-, Qualifizierungs-, Führungs-, Benutzungs- und Transferprozesse.

Die Geoinformationen des amtlichen Vermessungswesens bestehen aus den originären Bestandsdaten und den temporären Datenbeständen der Erhebungsdaten, Fortführungsdaten, Ausgabedaten und Transferdaten.

Die Projektsteuerung im AAA-Basisschema steuert den Ablauf aller Prozesse in Form von Vorgängen und Aktivitäten, womit vollständige Geschäftsprozesse beschrieben werden können. Sie stellt lediglich eine optionale Rahmenvorgabe dar, die inhaltlich durch die länderspezifischen Geschäftsprozesse zu untersetzen ist. In der Abbildung 35 werden die Prozesse und Daten der Geoinformationen des amtlichen Vermessungswesens dargestellt. Die im Rahmen des AdV-Projektes "Modellierung der Geoinformationen des amtlichen Vermessungswesens" fachlich zu modellierenden Bestandteile werden von einer gestrichelten Linie umrahmt.

Zu einem Prozess gehören mehrere aufeinander aufbauende Aktivitäten, die zu Vorgängen zusammengefasst und fachlich gegliedert werden können. Zur Beschreibung der Prozesse (Vorgänge und Aktivitäten) werden folgende Sprachmittel verwendet:

Für eine vollständige Anwendungsbeschreibung sind Vorgänge und Aktivitäten zu definieren, die Daten in funktionelle Abhängigkeiten setzen und das dynamische Verhalten der Anwendung definieren. Vorgänge sind den einzelnen Prozessen im AAA-Anwendungsschema zugeordnet. Dies kann aus der Abbildung 36 entnommen werden.

Ein Vorgang beinhaltet die Darstellung von Bearbeitungsschritten der Prozesse Qualifizierung, Führung, Benutzung und Übertragung, in denen auf verschiedene Aktivitäten verwiesen wird.

Eine Aktivität beschreibt das Verhalten eines Objekts und besteht aus einer Sequenz von Anweisungen. Den Anstoß dazu erhält ein Objekt durch eine Nachricht, die durch Eingaben des Nutzers oder durch Aktivitäten anderer Objekte ausgelöst werden (Eingabeparameter). Das Ergebnis der Aktivität wird in Form von Ausgabeparametern bereitgestellt. Aktivitäten werden objektbezogen definiert und sind im UML-Modell Bestandteil einer Klasse.

Mit einem Prozess wird ein Quelldatenbestand in einen Zieldatenbestand überführt. Der Benutzungsprozess beispielsweise überführt die Bestandsdaten in temporäre Ausgabedaten.

Zur Steuerung der verschiedenen Prozesse werden spezielle Klassen gebildet, die Steuerungsparameter für den Ablauf von Prozessen beinhalten, wie z. B. "AX_Benutzungsauftrag" im Benutzungsprozess des AAA-Anwendungsschemas.

Dreh- und Angelpunkt der Projektsteuerung ist die Objektart AA_Antrag. Diese Objektart realisiert eine "Mini-Antragsverwaltung", d.h. eine Schnittstelle zur externen Antragsverwaltung. Dadurch wird es möglich, bei einem Eintrag in der externen Antragsverwaltung (Geschäftsbuch) direkt einen Bezug zu diesem Antrag (mit Raumbezug) zu generieren.

Das Antragsobjekt verwaltet außerdem die Wiedervorlage des Antrags und unterstützt die Überwachung der Projektsteuerungs-Objekte. Mit dem Raumbezug kann nach bestehenden Prozessen gesucht werden, um konkurrierende Anträge zu ermitteln oder um andere benachbarte Anträge bei der Bearbeitung zu berücksichtigen. Die fachliche Reihenfolge konkurrierender Anträge ist durch den Sachbearbeiter festzulegen. Das Antrags-Objekt wird mit dem Projektsteuerungs-Objekt (AA_Projektsteuerung) verbunden, um die Zuordnung des Antrags zu einem oder mehreren Projektsteuerungs-Objekten festzulegen und um die nicht zulässigen Kombinationen zu überwachen. Weiterhin steuert und überwacht das Projektsteuerungs-Objekt die korrekte Abwicklung der Vorgänge im Teilprozess "fachtechnische Qualifizierung". Die Fortführungsanlässe werden beim Projektsteuerungs-Objekt geführt.

Der Vorgang ist Teil einer Projektsteuerung und setzt sich aus einzelnen Aktivitäten zusammen. Die Vorgänge stellen in sich abgeschlossene Arbeitsschritte dar. Ein vorzugebender Arbeitsablauf ("Workflow") legt die Reihenfolge und Abhängigkeiten der Vorgänge und deren Arbeitsschritte fest. Die Vorgänge werden in Gruppen zusammengefasst und in einer bestimmten Reihenfolge nacheinander bzw. nebeneinander bearbeitet. Die Entscheidung über den Abschluss des einzelnen Vorganges wird im Status (Meilenstein) dokumentiert.

Der Projektsteuerungskatalog definiert die innerhalb eines Projektsteuerungs-Objektes dieser Art erlaubten Fortführungsanlässe. Er beinhaltet die Projektsteuerungs- und Vorgangsarten. Die Projektsteuerungsart bündelt Projektsteuerungs-Objekte, die eine gemeinsame Charakteristik aufweisen. Analoges gilt für die Vorgangsart.

Hierbei handelt es sich um einen Datentyp, der zu einem Vorgang usw. den aktuellen Zustand und die Verantwortlichkeiten vermerkt.

Eine anwendungsbezogene Erläuterung der Projektsteuerung des AAA-Basisschemas für das Fachschema ALKIS befindet sich in der GeoInfoDok in den "Erläuterungen zu ALKIS". Weitere Einzelheiten und Zusammenhänge können hieraus entnommen werden.

Anwendungsschema

Das AAA-Anwendungsschema wurde auf der Basis der Regeln für Anwendungsschemata aus ISO/TS 19103 und ISO 19109 entwickelt.

Zur größeren Klarheit werden im Anwendungsschema die folgenden zusätzlichen Stereotypen verwendet:

Zusätzlich werden UML Tagged Values wie in ISO 19136 E.2.1 spezifiziert im Modell verwendet sowie zwei weitere UML Tagged Values "xsdEncodingRule" und "reverseRoleNAS" unterstützt. Hierbei gelten die folgenden Regeln:

Zeichensatz und unterstützte Sprachen

Wie in ISO 19118 A.2.3 spezifiziert, soll grundsätzlich der Universal Character Set (UCS) von "ISO-10646-1" als Zeichenvorrat verwendet werden. Dieser ist identisch mit dem Unicode Character Repertoire.

Als Character Encoding für NAS-Daten soll einheitlich "UTF-8" (UTF = UCS Transformation Format) verwendet werden. "UTF-8" ist auch der Standardwert in XML, falls eine Encoding-Angabe fehlt. Gemäß der Vorgaben des IT-Planungsrates [KOSIT-01] wird eine Teilmenge von Unicode als Zeichensatz verwendet.

Sprache ist Deutsch ("de") oder Sorbisch (Niedersorbisch bzw. Obersorbisch).

Exchange Metadata

Im Zuge der Modellierung der Aufträge und Ergebnisse werden jeweils die erforderlichen Exchange Metadata modelliert und mit der automatischen Umsetzung nach XML Schema überführt.

Identifikatoren

Identifikatoren sind in der NAS nur auf der Ebene der Fachobjekte definiert, d.h. in allen XML-Elementen, die Typen repräsentieren, welche eine Unterklasse von AA_Objekt sind. Bei diesen sind die Identifikatoren stets anzugeben (mit Ausnahme der weiter unten definierten Fälle). Identifikatoren an allen übrigen Elementen werden überlesen und nicht beachtet.

Die Identifikatoren an Fachobjekten sind stets im Sinne von UUIDs zu verstehen, d.h. sie sind innerhalb der "AFIS-ALKIS-ATKIS-Application-Domain" eindeutig.

Der AAA-Identifikator besteht stets aus 16 Zeichen. Der Aufbau wird in Abschnitt 3.3.9 beschrieben.

Updatemechanismen

Ein Updatemechanismus im Sinne von ISO 19118 Kapitel 8 wird über die NAS-Operationen unterstützt.

Das AAA-Anwendungsschema verwendet einige Konstruktionen in UML, die in den Abbildungsregeln von ISO 19136 Annex E, GML 3.3 Kapitel 12 und ISO/TS 19139 nicht unterstützt werden, bzw. die für die Codierung vereinfacht werden sollen. Daher erfolgt eine skriptgestützte Umsetzung des konzeptuellen AAA-Anwendungsschemas in UML in ein Implementierungsschema (siehe oben TBD: Genaue Referenz?). Hierzu wird ein neues Paket "NAS" als Kopie des Pakets "AFIS-ALKIS-ATKIS Anwendungsschema" angelegt und transformiert.

Das Skript nimmt die folgenden Änderungen vor:

Das Instanzenschema wird auf der Basis des Implementierungsschemas von ISO 19136 E.2.2 übernommen.

Die Ausgabedatenstruktur ist unter ISO 19136 E.2.3 erläutert.

Relevante Fundstellen für die Schema-Abbildungsregeln sind: ISO 19136 E.2.4 mit den Erweiterungen aus GML 3.3 Kapitel 12 und - für Klassen mit dem UML Tagged Value xsdEncodingRule mit dem Wert "iso19139_2007" - ISO/TS 19139 Kapitel 8.

Die Werte des UML Tagged Value "reverseRoleNAS" werden im XML Schema in appinfo-Annotationen an dem Element ausgegeben, das der Assoziationsrolle entspricht.

Das von der AdV spezifizierte Schema für WFS-Erweiterungen codiert die in Abschnitt 5.1.3 beschriebenen Erweiterungen.

Die importierten, von Dritten definierten und verwalteten Schemata (OWS Common 1.1, GML 3.2, GML 3.3, Xlink 1.1, ISO/TS 19139:2007, WFS 2.0 und Filter Encoding 2.0 werden in den jeweiligen kanonischen Schema-Repositories referenziert.

Abbildungsregeln für Instanzen

Dieser Abschnitt beschreibt die Abbildung des Instanzenmodells in entsprechende XML-Elemente. Das Ergebnis der Abbildung ist ein valides XML-Dokument (NAS-Dokument). Entsprechend gezippte XML-Dokumente sind ebenfalls gültige NAS-Dokumente. Als Komprimierungsverfahren zugelassen sind "zip" und "gzip".

Die Datei enthält:

Jedes Objekt im Instanzenschema wird in ein entsprechendes Element überführt. Das passende Element trägt denselben Namen wie die Klasse, zu der das Objekt gehört. Das "gml:id"-Attribut, das den Identifikator trägt, wird gesetzt.

Jede Eigenschaft des Objekts, d.h. jedes Attribut und jede Rolle in einer Assoziation, wird entsprechend der in den Schema-Abbildungsregeln definierten Abbildung auf XML-Elemente abgebildet, i.d.R. in ein lokales Element mit dem Namen des Attributs oder der Rolle.

Codierung von Identifikatoren in der NAS

Der AAA-Identifikator besteht stets aus 16 Zeichen. Der Aufbau wird in Abschnitt 3.3.9 beschrieben.

In der NAS ist der AAA-Identifikator im XML-Attribut gml:id zu codieren. Beispiel:

Um die dokumentenweite Eindeutigkeit des gml:id-Attributs zu gewährleisten, wird die Angabe immer dann um Entstehungsdatum/-zeit ergänzt, wenn mehrere Versionen eines Objekts in einem XML-Dokument vorkommen. Dies kommt insbesondere in den folgenden Fällen vor:

Datum und Uhrzeit werden hierbei in 16 Zeichen ohne Trennzeichen kodiert, damit sie den Bedingungen einer XML ID genügen, also in der folgenden Form: CCYYMMDDThhmmssZ.

Beispiel:

Zusätzlich zur gml:id ist der Identifikator ebenfalls in der in ISO 19136 vordefinierten Objekteigenschaft, gml:identifier, zu codieren. Hierbei gelten die folgenden Regeln:

Beispiel:

In der NAS kommen zwei Arten von Verweisen auf Objekte vor:

Codierung von Geometrieeigenschaften in der NAS

Auf die Kodierung der Orientierung von Linien (Curves) wurde im AAA-Basisschema verzichtet. Da die Richtung einer Linie aber fallweise (z.B. Fließrichtung von Gewässern) eine Bedeutung hat, muss a) die Erfassung in positiver Richtung erfolgen und b) sichergestellt werden, dass diese Richtung im Zuge der Verarbeitung und Speicherung unverändert bleibt. Damit kann davon ausgegangen werden, dass die Linienorientierung in der NAS immer positiv ist und es einer gesonderten Kennzeichnung nicht bedarf.

Bei Flächenumringen liegt die begrenzte Fläche gemäß ISO 19107 immer zur Linken der in positiver Richtung orientierten begrenzenden Linien.

Um die NAS möglichst einfach zu gestalten, wird Geometrie ausschließlich redundant ausgetauscht. NAS-Daten aufnehmende Programmsysteme müssen Topologie bzw. gemeinsame Geometrienutzung selbst erkennen - sofern sie sich für diese Information interessieren. Die Einstiegshürde für die Nutzung von AFIS-ALKIS-ATKIS-Daten wird dadurch möglichst niedrig gehalten.

Das "Erkennen" von Geometrieteilung wird durch die folgenden Punkte - auf möglichst einfache Weise - definiert.

Topologische Objekte und solche mit gemeinsam genutzter Geometrie können Themen zugeordnet werden. Topologische Beziehungen und gemeinsame Geometrienutzung sind nur innerhalb eines Themas möglich. Ein Thema ist immer auf eine Modellart beschränkt.

Damit zwei Geometrien identisch sind, müssen sie identische Definitionen in einem <Point> bzw. einer <Curve> besitzen, ein identischer Geometrieverlauf allein ist bei Linien nicht ausreichend.

Zur Erläuterung folgende Themendefinition für die Modellart Basis-DLM

Zur Erläuterung hier ein Beispiel bestehend aus 42003 AX_Strassenachse, 41006 AX_FlaecheGemischterNutzung und 41008 AX_SportFreizeitUndErholungsflaeche, welche aufgrund der Themendefinition in gemeinsamen Positionen über identische Koordinatenpaare verfügen.

Identität bei Linien wird stets auf der Ebene der "GM_Curve" untersucht. Sie ist gegeben, wenn alle Positionen der Geometriedefinition in Lage und Reihenfolge sowie verwendeter Interpolationsart identisch sind. Hierbei ist auch eine Umkehrung der Reihenfolge erlaubt.

Zwei Positionen sind identisch, wenn ihr Abstand kleiner als die vorzugebende Koordinatenauflösung ist. In AFIS-ALKIS-ATKIS ist diese für metrische Lagekoordinaten auf 3 Nachkommastellen (mm) festgelegt. Diese Festlegung gilt unabhängig von der tatsächlichen Genauigkeit der Koordinaten.

Zur Erläuterung werden die beiden Situationen aus Abbildung 44 beispielhaft codiert. Zuerst die linke Situation (ohne Linienteilung):

Und zum Vergleich die rechte Situation, bei der die untere Kante des Flurstücks zur Herstellung der Geometrieidentität im oben beschriebenen Sinne in zwei Kanten in der Erhebungskomponente aufgetrennt wurde:

Die Themen werden in der NAS-Datei wie folgt abgebildet:

Die bis zur GeoInfoDok Version 6.0.1 mögliche, instanzenbezogene Angabe der geometrischen Identität ist nicht mehr vorgesehen, da eine eindeutige Zuordnung zwischen einer geometrischen Identität und dem entsprechenden Thema nicht möglich war, sondern nur allgemeingültig für alle Instanzen in den Produkt-Metadaten angegeben werden konnte. Zudem waren keine fachlichen Anforderungen zur Erfassung und Führung dieser Funktionalität bekannt.

Codierung von Verweisen auf Koordinatenreferenzsysteme in der NAS

Grundsätzlich muss jede Geometrieeinheit in der NAS-Datei (Punkt, Linie, Fläche) auf ein Koordinatenreferenzsystem (CRS) verweisen. Dies kann entweder implizit durch Angabe des CRS bei einer übergeordneten Geometrieeinheit oder explizit bei der jeweiligen Geometrieeinheit erfolgen. Der Verweis erfolgt durch Angabe eines URI (Uniform Resource Identifier). Um diese Angabe nicht immer bei jeder Objektgeometrie machen zu müssen, werden in den Exchange Metadata der NAS alle verwendeten Referenzsysteme angegeben, von denen eines als Standardreferenzsystem gekennzeichnet werden kann. Für Geometrien, die in diesem Standardreferenzsystem vorliegen, muss keine Angabe zum Koordinatenreferenzsystem mehr gemacht werden. Das dafür vorgesehene Attribut bei GML-Geometrien "srsName" ist in diesen Fällen nicht vorhanden. Für alle Geometrien, die nicht im Standardreferenzsystem vorliegen, ist das Attribut zu belegen. Hierbei sind die in Abschnitt 8.1 beschriebene Syntax und die dort definierten Bezeichnungen zu verwenden.

Bei NAS-Dokumenten, die Objekte in einer "FeatureCollection" enthalten, ist das Standardreferenzsystem im Attribut "srsName" des "gml:Envelope" anzugeben.

Darüber hinaus dient die Deklaration der verwendeten Koordinatenreferenzsysteme in den Exchange Metadata der Angabe der für das Referenzsystem geltenden Koordinatenauflösung bzw. der Anzahl der relevanten Nachkommastellen. Diese kann von Referenzsystem zu Referenzsystem unterschiedlich sein und macht keine Aussage über die Genauigkeit der Koordinaten. In AFIS-ALKIS-ATKIS ist die Koordinatenauflösung für metrische Lagekoordinaten auf 3 Nachkommastellen (mm) festgelegt. Die Angabe der relevanten Nachkommastellen ist notwendig, da sowohl GML als auch ISO 19107 Spatial Schema keine Einschränkungen diesbezüglich machen und auch keine Möglichkeiten dazu vorsehen (Datentyp: decimal oder double). Folgende Definition wird in den NAS Schema-Dateien verwendet:

Codierung von Verweisen auf Maßeinheiten in der NAS

Grundsätzlich muss jeder mit einer Maßeinheit versehene Wert in der NAS-Datei (z.B. Längen, Flächen, Winkel) auf eine Maßeinheit verweisen. Der Verweis erfolgt durch Angabe eines URI (Uniform Resource Identifier) im Attribut "uom". Hierbei sind die in Abschnitt 8.2 beschriebene Syntax und die dort definierten Bezeichnungen zu verwenden.

Codierung von Verweisen auf Werte aus Codelisten

Jedes Attribut mit einem Wert aus einer Codelist wird in der NAS als Verweis auf einen Codelistenwert in einer Registry für Codelisten (siehe Abschnitt 7.2) codiert. Der Verweis wird als HTTP URI in einem xlink:href-Attribut codiert. Hierbei ist der Text des Wertes im Attribut xlink:title aufzunehmen.

Beispiel:

Codierung von Zeilenumbrüchen in Schriftinhalten von Präsentationsobjekten

Für eine korrekte Darstellung von Schriftinhalten wird gelegentlich ein Zeilenumbruch nötig. Dieser muss im Schriftinhalt eines Präsentationsobjektes durch ein entsrechendes LF-Zeichen "\n" angegeben werden. In XML wird ein LF durch ein Zeichen - typischerweise #xA - repräsentiert.

Da GML selbst keine Elemente für Fortführungsoperationen anbietet, werden zu diesem Zweck die Festlegungen des Web Feature Service (WFS) von OGC verwendet. In der WFS-Spezifikation sind neben dem Transaktionsmechanismus 4 Änderungsfunktionen definiert: <Insert> (neues Objekt einfügen), <Update> (Objekt ändern), <Replace> (Objekt überschreiben) und <Delete> (Objekt löschen). In der NAS wird bei der Fortführung von Primärnachweisen <Update> nicht verwendet. Welche Änderungen zu <Replace> oder zu <Delete> mit anschließendem <Insert> führen, ist in den Objektartenkatalogen fachlich festzulegen. Dies gilt sowohl für Änderungen in den Attributwerten und Relationen als auch für geometrische Änderungen. Bei letzteren muss ggf. der Bearbeiter im Erhebungsprozess entscheiden, welche Fortführungsart zu verwenden ist.

Beispiel:

Folgendes ist zu beachten:

Die XML-Schemata für einen Fortführungsauftrag und sein Ergebnis sind wie alle anderen NAS-Operationen in der Datei NAS-Operationen.xsd enthalten. Einrichtungsaufträge und deren Ergebnisse sind Unterklassen von Fortführungsaufträgen.

Die Funktionen zur Fortführung werden in Systemen mit vollständigem Nachweis der Historie und in Systemen ohne vollständige Historie unterschiedlich ausgeführt:

Systeme ohne vollständigen Historiennachweis

<Insert>:
Die übermittelten Fachobjekte werden als neue Informationen eingetragen.

<Replace>:
Die übermittelten Fachobjekte ersetzen die Fachobjekte, die denselben Identifikator haben. Zur eindeutigen Bezeichnung der zu überschreibenden bzw. zu versionierenden Version wird der Identifikator (XML-Attribut rid) des neuen Fachobjekts im Filterausdruck um die Angabe des Entstehungsdatums/-zeit der zu überschreibenden Objektversion ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Im aufnehmenden System wird das Fachobjekt wieder mit dem originalen (nicht um Entstehungsdatum/-zeit ergänzten) Identifikator gespeichert. Es ist nicht zulässig, die Operation <Replace> durch <Delete> und nachfolgendes <Insert> mit demselben Identifikator zu ersetzen.

<Delete>:
Das Attribut rid des Filterausdrucks im WFS-<Delete>-Element bezeichnet das zu löschende Fachobjekt. Zur eindeutigen Bezeichnung der zu löschenden Version wird der Identifikator in der Austauschdatei um die Angabe des Entstehungsdatums/-zeit der zu löschenden Version ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Das so bezeichnete Objekt wird im aufnehmenden System mit allen selbstbezogenen Eigenschaften und referenzierten Raumbezugsgrundformen gelöscht. Raumbezugsgrundformen werden nur dann gelöscht, wenn sie von keinem weiteren Objekt referenziert werden.

Diese Funktionalität wird vor allem von Datenhaltungssystemen genutzt, die Sekundärdatenbestände halten.

Systeme mit vollständigem Historiennachweis

Ist das aufnehmende System zur Führung eines vollständigen Historiennachweises konfiguriert, reagiert es auf

<Insert>
mit der Erzeugung einer neuen Instanz eines Objektbehälters und fügt in den Behälter eine erste Version des übermittelten Fachobjekts ein.

<Replace>
Die übermittelten Fachobjekte werden als neue Version in den durch den Identifikator bezeichneten Objektbehälter eingetragen. Zur eindeutigen Bezeichnung der Vorgängerversion wird der Identifikator im Filterausdruck (XML-Attribut rid) des neuen Fachobjekts in der Austauschdatei um die Angabe des Entstehungsdatums/-zeit der zu überschreibenden Objektversion ergänzt. Damit sollen Fehler aufgedeckt werden, die durch Fortführungsaufträge entstehen könnten, die nicht zum gespeicherten Datenbestand passen. Im aufnehmenden System bleibt das überschriebene Fachobjekt als historische Version bestehen.

<Delete>
Die im Filterausdruck durch den um Entstehungsdatum/-zeit erweiterten Identifikator (XML-Attribut rid) bezeichnete Version des Fachobjekts wird mit dem aktuellen Untergangsdatum/-zeit (aus der Systemzeit abgeleitet) versehen und dadurch historisiert. Das System stellt sicher, dass keine weiteren Versionen angelegt werden können.

Diese Funktionalität wird auch von den Datenhaltungssystemen genutzt, die die Versionierung nur befristet zur Bereitstellung von Fortführungsinformationen für Dritte im Rahmen des NBA-Verfahrens (s.u.) verwenden.

Das konzeptuelle Fachmodell für die Fortführung von ALKIS sowie die Abläufe bei dessen Fortführungsverarbeitung sind im Abschnitt "Erläuterungen zu ALKIS" TBD: Genaue Referenz? beschrieben.

Hinweis: Das Fortführungsergebnis liefert derzeit nur minimale Informationen zurück. Grundsätzlich sinnvoll wären eine Gegenüberstellung von temporären und endgültigen Identifikatoren sowie eine Rückgabe von Entstehungsdatum/-zeit pro Fortführungsfall. Da dies in der aktuellen Version nicht erfolgt, müssen diese Informationen bei Bedarf, z.B. zur Codierung von Folgefortführungen, über einen nachfolgenden Bestandsdatenauszug aus der DHK erfragt werden.

Die aus einem Datenhaltungssystem auszugebenden Daten (Benutzungsdaten oder Daten zur Führung von Sekundärnachweisen) werden hinsichtlich des auszugebenden Informationsumfangs durch Kriterien zur Selektion und Filterung bestimmt. Ein Datenhaltungssystem muss deshalb in der Lage sein, komplexe Selektions- und Filterausdrücke auszuwerten und die sich damit qualifizierenden Daten auszugeben. Die Selektion erfolgt durch räumliche, fachliche (Objektart, Attribut, Relation) und zeitliche Kriterien. Diese Kriterien können auch geschachtelt und miteinander verbunden werden, so dass ganze Selektionsketten entstehen. Damit kann auch formuliert werden, welche Elemente weitere Elemente über Referenzen zur Ausgabe nachziehen. In der NAS wird stets nur die im Anwendungsschema als navigierbare Richtung gekennzeichnete Rolle der Assoziation angegeben. Gegenrelationen sind in der NAS nicht zulässig. Gleichwohl ist es zur Vereinfachung von Filterausdrücken möglich, Objekte anzufordern, die per Gegenrelation mit einem Objekt verbunden sind. Hierbei ist - soweit vorhanden - der explizit im Modell benannte Rollenname der Gegenrelation zu verwenden, in Ermangelung eines solchen der um "inversZu_" ergänzte Rollenname der als navigierbare Richtung gekennzeichneten Rolle.

Kriterien der Filterung bestimmen, welche Elemente der Selektionskette ausgegeben werden sollen und welche Attribute und Verweise mit diesen Elementen ausgegeben werden.

Die Selektions- und Filterungskriterien werden als Bestandteil der Benutzungsanforderung an das datenführende System übermittelt oder dort in Benutzerprofilen hinterlegt. Für die Definition einheitlicher Produkte der AdV werden einheitliche Selektions- und Filterkriterien definiert. Als formale Sprache zur Definition der Selektionsketten wird die Filter Encoding Specification von OGC verwendet.

Das XML-Schema für einen Benutzungsauftrag ist in der Datei NAS-Operationen.xsd enthalten. Es nutzt das Schema filter.xsd von OGC.

Grundsätze für die Selektion von Objekten (Filter Encoding)

Zum Codieren einer Selektion wird das <wfs:Query>-Element aus der "Web Feature Service"-Spezifikation (WFS) des Open Geospatial Consortiums in der Version 2.0 verwendet. In einer Selektion können mehrere Queries vorkommen, wobei sich jede Query auf eine instanziierbare Objektart bezieht. Die unterschiedlichen Queries wirken ergänzend.

Die aktuelle Filter-Encoding-Spezifikation unterstützt bei Ad-Hoc-Queries und den geforderten Konformitätsklassen nur die Angabe der konkreten, instanziierten Objektarten, d.h. die im AAA-Anwendungsschema modellierte Vererbungshierarchie wird nicht unterstützt. Es ist also z.B. nicht möglich, eine einzige Query für "AX_TatsaechlicheNutzung" abzusetzen, um alle TN-Objekte zu erfragen, sondern es muss ein <wfs:Query>-Element pro Objektart angegeben werden. Hierfür wäre eine Unterstützung der Konformitätsklasse "Schema Element Function" erforderlich. Queries auf Modellelemente mit Stereotype und Tagged Value "retired" sind ohne Einschränkungen möglich.

In eine <wfs:Query> eingebettet ist u.a. ein <fes:Filter>-Element zur Filterung der Objekte aus dem Gesamtumfang der Objektart. Ein <fes:Filter>-Ausdruck besteht aus einem Prädikat, das für jedes Objekt der Objektart in der Datenbasis, auf der die Suche ausgeführt werden soll, angewendet wird. Erfüllt das Objekt das Prädikat, ist es Teil der Selektion, ansonsten nicht. Die Prädikate sind entsprechend so zu verstehen, dass sie grundsätzlich auf den XML-Instanzen wirken, die diese Objekte repräsentieren.

Entsprechend besteht das Prädikat aus einem booleschen Ausdruck, der aus beliebig vielen atomaren Operatoren besteht, die über

Bei den atomaren Operatoren werden

und

unterstützt. Die Bedeutung der logischen Operatoren und der Vergleichsoperatoren ergibt sich aus der in SQL verwendeten bzw. der direkt mit dem Namen ausgedrückten Bedeutung.

Die Bedeutung der räumlichen Operatoren ist i.d.R. in der OpenGIS Simple Features Spezifikation definiert und in das Filter Encoding übernommen worden. Vermutlich ist <fes:Intersects> der wichtigste Operator, der "true" ergibt, wenn zwei Geometrien nicht überschneidungsfrei sind. <fes:BBOX> ist eine vereinfachte Form, die als Testgeometrie nur eine Bounding Box erlaubt. <fes:Disjoint> ist die Umkehrung zu <fes:Intersects>. <fes:Contains> oder <fes:Within> sind zu verwenden, wenn es nicht um Überlappung geht, sondern um echtes Enthaltensein. Für weitergehende Fragen, siehe die OpenGIS Spezifikationen Filter Encoding und Simple Features for SQL.

Bei räumlichen Operatoren und den Vergleichsoperatoren wird i.d.R. eine Eigenschaft des Objekts angegeben, für die der Vergleich durchgeführt werden soll.

Dies geschieht unter Verwendung von Xpath, dabei beschränkt man sich auf die Kurzschreibweise. Dies bedeutet:

Hierbei wird davon ausgegangen, dass der Default-Namespace des XML-Dokuments "http://www.adv-online.de/namespaces/adv/gid/version" ist. Ansonsten sind alle Bezeichner durch das Namespacekürzel zu qualifizieren (wie dies im Beispiel von xlink:href oben bereits erfolgt ist), also in der Regel

statt

Im Fall von einfachen Attributen wird i.d.R. der Vergleichsoperator den Attributwert mit einem festen Wert vergleichen (Element <fes:Literal>), z.B.

was für alle Objekte in der Datenbasis erfüllt ist, bei denen das Stellenart-Attribut einen entsprechenden Wert (Werteart 1100) aufweist, oder

oder

oder im Fall der Prüfung auf einen nicht vorhandenen Wert

Für den Operator <PropertyIsNotEqualTo> des OGC-Filter Encodings gehören keine NULL-Werte zur Ergebnismenge. <PropertyIsNotEqualTo> liefert somit zu <PropertyIsEqualTo> keine komplementären Mengen zurück, sodass eine zusätzliche <PropertyIsNull>-Abfrage hinzugenommen werden muss.

Dies ist beispielsweise bei einer Abfrage nach allen Flustücksnennern ungleich 3 bezogen auf folgenden Gesamtbestand der Fall: Flurstück 100/1, 100/2, 100/3, 111. <PropertyIsNotEqualTo> 3 </PropertyIsNotEqualTo> würde liefern: Flurstücke 100/1, 100/2, nicht aber 111.

Für die Prüfung auf Werte in einem Bereich, z.B. für die Prüfung ob die Stellenart ein Wert im 1xxx-Bereich ist, würde folgender Vergleich verwendet:

Analog ein Prädikat für Flurstücke mit einer amtlichen Fläche von mindestens 1000qm aber maximal 2000qm:

Der LIKE-Vergleich ist für flexible Textvergleiche hilfreich. So filtert das folgende Prädikat alle Anschriften heraus, deren Telefonnummer mit 0228 beginnt

während das folgende Prädikat die Personen filtert, bei denen der Geburtsname gesetzt ist, mit einem "M" beginnt und als dritten und vierten Buchstaben ein "t" hat:

Bei räumlichen Operatoren erfolgt ein Vergleich einer Eigenschaft (der Name der geometrischen Attributart) mit einer festen Geometrie analog zu den Vergleichen einer textlichen oder numerischen Eigenschaft mit einem festen Wert. Bei den räumlichen Operatoren wird der feste Wert statt durch ein <fes:Literal>-Element durch das jeweilige GML-Geometrieelement ausgedrückt, zum Beispiel

Sofern der Gesamtschlüssel eines Katalogeintrags bekannt ist, kann der entsprechende Katalogeintrag z.B. mit einer Query der folgenden Art erfragt werden (hier die Gemarkung mit der Kennung "071234"):

Sollen alle Katalogeinträge mit einem bestimmten Teilschlüssel erfragt werden, dann kann entweder mit <fes:PropertyIsLike> oder mit Vergleichsoperatoren für die einzelnen Attribute des Schlüssel-Datentyps gesucht werden. Alle Gemarkungen im Land findet man z.B. mit:

oder

Neben der Filter-Bedingung können in das <wfs:Query>-Element noch weitere Elemente eingebettet sein. Das Element <wfs:PropertyName> mit dem Attribut resolve="local" kann dazu genutzt werden, mit einer Query auf einen Schlag auch noch weitere Objekte in die Ergebnismenge aufzunehmen. Auf diese Weise kann die Anzahl der Queries - und damit auch der Benutzungsaufträge - häufig deutlich reduziert werden.

Das Element

in einer AX_Flurstueck-Query führt dazu, dass entlang der Relation gehoertAnteiligZu alle Relationspartner bis zu einer Tiefe von 1 (also die direkten Relationspartner, in diesem Fall die betroffenen Flurstücke) in die Ergebnismenge aufgenommen werden.

Ein anderes Beispiel, dass alle Punktorte mit unanhängiger Geometrie sowie alle ihre ZUSOs zurückliefert:

Eine weitere Präzisierung der Abfrage wird durch das Attribut resolvePath unterstützt, das dazu führt, dass nicht in der Breite, sondern genau die Objekte entlang des Pfades in die Ergebnismenge aufgenommen werden.

Das Element <wfsext:PropertyName> aus dem Schema "WFS-Erweiterungen" hat die- selbe Semantik wie das Element <wfs:PropertyName> aus dem WFS-Schema ohne das Attribut resolveDepth und erweitert dieses um zwei zusätzliche Fähigkeiten. Wird das Elemente mit dem Attribut resolvePath und 'this' als als Name der Eigenschaft verwendet, dann stelllt das Schlüsselwort 'this' eine Relation auf das Ausgangsobjekt selbst dar, so dass - anders als bei <wfs:PropertyName> aus dem WFS 2.0 Standard - der vollständige Relationspfad ausgehend von der Objektart der Query in resolvePath angegeben wird. Dies ermöglicht, dass alle darin enthaltenen Objektarten auf der Ebene instanziierbarer Objektarten angegeben werden können.

Bei Verwendung des Elements <wfsext:PropertyName> ist die Angabe der letzten Zielobjektart im Relationspfad optional, d. h. sie kann weggelassen werden, damit sich im Falle einer abstrakten Zielobjektart alle abgeleiteten instanziierbaren Objektarten qualifizieren. Die folgende Query liefert alle neben allen Punktorten mit unabhängiger Geometrie auch alle zugehörigen Schwerefestpunkte sowie alle übrigen REOs und NREOs der Schwerefestpunkte zurück.

Des Weiteren kann durch die Angabe des Attributs 'leafOnly' mit dem Wert 'true' die Erweiterung der Ergebnismenge auf die Objekte am Ende des Pfads in resolvePath eingeschränkt werden. Die übrigen Objekte entlang des Pfads werden nicht zurückgeliefert. Die folgende Query hat dieselbe Wirkung wie die vorherige Query mit der Änderung, dass keine Schwerefestpunkte zurückgeliefert werden.

Sofern nur einzelne, ganz bestimmte nachgeordnete Objekte benötigt werden (in den Beispielen nur für wenige Punktorte die Punkte oder weitere Bestandteile der Punkte), dann bietet es sich i.d.R. an, die Selektion in zwei Abfragen aufzuteilen. Die erste Abfrage zur Selektion der Punktorte und anschließend die gezielte Selektion der benötigten Punkte.

Die nachfolgenden Tabellen geben einen Überblick, wie die Attribute resolve, resolveDepth und resolvePath das Ergebnis einer Flurstücks-Query beeinflussen können.

Die erste Tabelle verwendet dabei die Query nach dem Muster:

Es kann somit entweder nur 'resolvePath' oder nur 'resolveDepth' in einer Query verwendet werden, aber nicht beide gleichzeitig. Bei gleichzeitiger Angabe von 'resolvePath' und 'resolveDepth' ist letzterer Parameter zu ignorieren.

Die zweite Tabelle verwendet die Query nach dem Muster:

Bei 'Benutzungsergebnissen' erfolgt innerhalb einer <FeatureCollection> keine Klammerung in einer Ergebnismenge <AdditonalObjekts> für die zusätzlich über resolve, resolveDepth und resolvePath selektierten Objekte.

In der NAS werden alle Relationen nur in einer, der im UML-Modell als navigierbar ausgezeichneten Richtung repräsentiert. Die folgende Query erfragt alle Flurstücke und die Buchungsstellen unter denen diese gebucht sind:

Oder im Fall, dass ein Flurstück bekannt ist, dann kann aus dem <istGebucht>-Element der Identifikator der Buchungsstelle extrahiert werden (der String nach dem "urn:adv:oid:"-Präfix, in diesem Beispiel "DEBY123412345678") und die Buchungsstelle wie folgt erfragt werden:

In umgekehrter Richtung, d.h. von der Buchungsstelle zum Flurstück ist die Relation zwar auch benannt ("grundstueckBestehtAus"), aber nicht in der NAS repräsentiert. Sollen nun die Flurstücke ermittelt werden, die über "istGebucht" einer bestimmten Buchungsstelle (im Beispiel wird wieder die ID "DEBY123412345678" verwendet) zugeordnet sind, so kann dies über die Prüfung der Relation erfolgen:

Eine äquivalente Abfrage (sofern sich Flurstück und Buchungsstelle in derselben lokalen Datenbasis befinden) ist

Eine Möglichkeit so etwas wie wfsext:PropertyName mit resolvePath auch in inverser Richtung, also das gleichzeitige Selektieren bestimmter Buchungsstellen und aller Flurstücke, die auf diese gebucht sind, besteht durch die Möglichkeit der Verwendung inverser Relationen in Filterausdrücken. Hier kann die Selektion stattdessen natürlich auch in zwei Schritten, d.h. über zwei Queries, erfolgen.

In aller Regel werden mehrere Queries erforderlich sein, um sich die Objekte aus dem Datenbestand zu besorgen, die für komplexere Abfragen benötigt werden. Hierbei wird aus den Ergebnissen der vorigen Query die neue Query formuliert. Sehr häufig werden hierbei Zugriffe auf die Katalogeinträge zum Entschlüsseln von Schlüsselwerten erforderlich sein.

In der NAS ist es unzulässig in einer WFS-Query durch die Angabe mehrerer Objektarten im Parameter 'typeNames' eine Verknüpfung als JOIN zu realisieren, auch wenn es diese Möglichkeit im WFS-Standard 2.0 gibt.

Zur Codierung von Selektionskriterien wird das <wfs:Query>-Element aus der Spezifikation "Web Feature Service, Version 2.0.2" in Verbindung mit den Festlegungen der Spezifikation "Filter Encoding, Version 2.0.2" des Open Geospatial Consortiums verwendet. In OGC wird üblicherweise die Version nur bis zur zweiten Stelle referenziert (z.B. WFS 2.0, GML 3.2). Anzuwenden ist dann jedoch jeweils der letzte Bugfix, der über die dritte Stelle versioniert wird, bei WFS 2.0 beispielsweise WFS 2.0.2.

Die Anforderungen an die Selektions- bzw. Filterfunktionalität von AFIS-ALKIS-ATKIS gingen in früheren GeoInfoDok-Versionen über die in den dabei zugrundeliegenden Versionen der OGC-Spezifikationen beschriebenen Funktionalitäten hinaus. Deshalb wurden bislang zusätzlich einige Erweiterungen festgeschrieben, die mit dieser Version nicht mehr erforderlich sind:

Darüber hinaus verwendet die GeoInfoDok noch einige wenige Festlegungen, die in dieser Form kein Bestandteil der oben genannten Spezifikationen sind:

Die Ausgabe von Benutzungsdaten ist eine Datenausgabe ohne explizite Angabe einer im aufnehmenden System auszuführenden Funktionalität. Eine spezielle Aufbereitung der Daten in Abhängigkeit von der Ausgabeanforderung (z.B. Herstellung der "flurstückszentrierten Sicht" in ALKIS) ist möglich, indem entsprechende temporäre Objekte ausgegeben werden.

Für das Ergebnis einer Benutzung wird die wfs:FeatureCollection aus dem Web Feature Service von OGC verwendet und für AAA entsprechend um weitere Informationen ergänzt. Für jede Art der Ausgabe wird je nach Benutzungsauftrag eine eigene Schema-Datei verwendet.

Die Führung von Sekundärnachweisen erfolgt über die Nutzerbezogene Bestandsdatenaktualisierung fallbezogen oder stichtagsbezogen. Die nachfolgenden Regelungen gelten unabhängig davon, ob das NBA-Verfahren stichtags- oder fallbezogen erfolgt.

Im Fall einer Führung der Sekundärdatenbank ohne vollständigen Historiennachweis, d.h. es ist in der Sekundärdatenbank stets nur der aktuelle Stand der Daten verfügbar, gelten die folgenden Regeln:

Im Fall einer Führung der Sekundärdatenbank mit vollständigem Historiennachweis, d.h. es werden in der Sekundärdatenbank zumindest temporär auch untergegangene Objekte und Objektversionen vorgehalten, gelten die folgenden Regeln:

Da in der Sekundärdatenhaltung nie eine Aktualitätsprüfung erfolgt, wird für die Führung von Sekundärnachweisen abweichend von der Führung von Primärnachweisen festgelegt, dass das Attribut rid des Filterausdrucks im <wfs:Delete>-, <wfs:Replace>- oder <wfs:Update>-Element nie um die Angabe des Entstehungsdatums/-zeit der vorhandenen Version ergänzt wird.

Diese Definitionen wurden so gewählt, dass möglichst weitgehend ein bestehender Web Feature Service ohne zusätzliche Anpassungen verwendet werden kann - insbesondere im Fall ohne Historienführung. Es ist allerdings erforderlich, dass der Web Feature Service die <wfs:Replace>-Operation der GeoInfoDok unterstützt.

Wenn eine Sekundärdatenhaltung NBA-Abgaben an ein Tertiärsystem vornehmen soll, muss diese sicherstellen, dass alle Aufnahmen aus Primärsystemen auch berücksichtigt werden. Können bei der Abgabe der Daten aus Primärsystemen an eine Sekundärdatenhaltung nicht alle Daten übernommen werden, gibt es 2 Möglichkeiten:

Um die unterschiedlichen Kundenanforderungen erfüllen zu können, ist bei Bedarf die entsprechende Möglichkeit in den Verfahrenslösungen zu implementieren.

Sperraufträge ermöglichen das Sperren von Objekten im Führungssystem gegen Fortführungen von Dritten durch Angabe einer Liste mit Objekt-Identifikatoren. Entsperraufträge heben die Sperrung wieder auf. Objekte mit Stereotype und Tagged Value "retired" können weder gesperrt noch entsperrt werden.

Zur Reservierung von Kennungen (z.B. für Vermessungspunkte, Flurstückskennzeichen, etc.) können entsprechende Aufträge an ein Führungssystem formuliert werden. In der Ergebnis-Datei erhält man eine Liste mit den angeforderten Kennungen.

Da für jede Operation der NAS sowohl eine Request- als auch eine Response-Klasse definiert wurden, wird in letzterer definiert, welche Protokollinformation bei der jeweiligen Operation ausgegeben wird. Sie sind somit in den bei den einzelnen Operationen enthalten.

Jede Software-Komponente, die eine NAS-Schnittstelle besitzt, sollte die GetCapabilities-Operation unterstützen.

Bei der Nutzung der NAS für die Kommunikation zwischen einem Qualifizierungs- bzw. Erfassungssystem und einem Führungssystem sind folgende implizite Funktionen notwendig:

Geometriebehandlung

Geometriebehandlung stellt eine Funktionalität der Datenbank (AAA-Führungskomponente) im Rahmen der Fortführungsverarbeitung dar. Dabei werden neue bzw. geänderte Geometrien so mit dem Altbestand verknüpft, dass bei geometrischen Identitäten zwischen Alt- und Neubestand in Abhängigkeit von der Themenzugehörigkeit der beteiligten Objekte redundanzfreie Geometrien entstehen.

Diese Funktionalität ist unabhängig von den Geometrie behandelnden bzw. Identitäten herstellenden Funktionen des Verarbeitungssystems (AAA-Verarbeitungskomponente) immer dann notwendig, wenn vom Verarbeitungssystem im Rahmen einer Fortführung nicht alle von geometrischen Operationen betroffenen Objekte an die AAA-Führungskomponente geliefert werden (z.B. bei einer Flurstückszerlegung nur das gelöschte und die neuen Flurstücke). Für die Geometriebehandlung gelten folgende Grundsätze:

Es gelten folgende geometrische Kriterien:

Eine Tabelle mit einer Zusammenstellung der Impliziten Funktionen im Führungsprozess für ein System zum Primärnachweis befindet sich in Abschnitt A.2 dieses Dokumentes.

Bei der Führung von Sekundärnachweisen über die Schnittstelle NAS baut das aufnehmende System (soweit vom Nutzer gewünscht) die Gegenreferenzen zu den ausgetauschten Referenzen auf und pflegt sie.

Replace-Befehle, bei denen das fortzuführende Objekt noch nicht im Datenbestand des Nutzers ist, sind bei der Übernahme wie Insert-Befehle zu behandeln. (Beispiel: Ein Nutzer erhält im Interessengebiet alle Flurstücke und die zugehörigen Eigentümer. Ein Flurstück wechselt seinen Eigentümer. Der Eigentümer ist aus Sicht des Nutzers neu (Insert) aus Sicht des ALKIS-Führungssystems aber alt (Replace), weil er bereits an Flurstücken außerhalb des Interessengebiets Eigentum hatte und deshalb seit langem im abgebenden System geführt wird, jedoch noch nie im System des Nutzers geführt wurde.)

Insert-Befehle, bei denen das einzutragende Objekt im Datenbestand des Nutzers bereits vorhanden ist, sind bei der Übernahme zu ignorieren. Ein aufnehmendes System muss Objektversionen verarbeiten können, deren Lebenszeitbeginn vor dem Intervallbeginn des NBA-Verfahrens liegt und im Abgabezeitraum nicht verändert wurde.

Eine Objektversion kann durch die neue Abgabeform mit gleichem Lebenszeitbeginn in unterschiedlichen Folgeabgaben auftauchen. Das aufnehmende System muss daher identische Versionen bei der Übernahme erkennen und ignorieren.

Eine Tabelle mit einer Zusammenstellung der Impliziten Funktionen im Führungsprozess für ein System zum Sekundärnachweis befindet sich in Abschnitt A.3 dieses Dokumentes.

Die fachlichen Anforderungen zur Nutzerbezogenen Bestandsdatenaktualisierung (NBA) gründen sich auf die vorhandenen Verfahren, wie sie in ALK/ATKIS und im ALB realisiert vorliegen. Diese Verfahren sind nicht identisch. Weitere fachliche Anforderungen lassen sich folgendermaßen zusammenfassen:

Änderungsdaten sind auf der Grundlage der Fortführungsdaten abzuleiten, die ihrerseits die Struktur der Bestandsdaten aufweisen. Änderungsdaten zur Nutzerbezogenen Bestandsdatenaktualisierung sollen:

Fortführungsfallbezogen bedeutet, dass alle Veränderungen, die in einem zurückliegenden Zeitraum stattgefunden haben, der zeitlichen Reihenfolge nach aufgeführt werden. Damit wird es möglich, alle Prozesse schrittweise im aufnehmenden System nachzuvollziehen. Voraussetzung ist allerdings, dass auch alle Informationen in den Änderungsdaten enthalten sind, die das Erzeugen, Ändern und Löschen von Objekten in dem zurückliegenden Zeitraum betreffen.

Im Gegensatz dazu liefert das stichtagsbezogene Verfahren nur die Differenzdaten, die nötig sind, um den Ausgangszustand beim Nutzer auf den vom Nutzer gewünschten Endzustand zu bringen. Was auf dem Weg zum Endzustand mit den Objekten geschehen ist, kann in diesem Fall nicht nachvollzogen werden. Die stichtagsbezogenen Differenzdaten stellen eine Untermenge der Änderungsdaten dar und können durch Auswertung aus ihnen abgeleitet werden; sie umfassen alle neu entstandenen Objekte, die jeweils aktuellen Versionen von fortgeführten Objekten sowie Angaben zu historisch gewordenen Objekten.

Für jeden Nutzer wird ein Profil angelegt, das beschreibt, nach welchen Kriterien der Nutzer mit Änderungsdaten aus dem einmal für das NBA-Verfahren vorgehaltenen Bestand versorgt werden soll. Dieses Profil ist vor der ersten Datenabgabe zu erstellen.

Für jeden Benutzer wird eine Profilkennung angegeben. Diese Kennung wird auch verwendet, um in der OA AX_NutzerbezogeneBestandsdatenaktualisierung_NBA eine automatische Abarbeitung der NBA-Dateien zu ermöglichen. Mit der Profilkennung kann eindeutig der Bezug zur AX_BenutzergruppeNBA hergestellt werden, welche die maßgeblichen Selektionskriterien des Nutzers enthält. Nutzerbezogene Selektionskriterien sind:

Objektarten, Attribute und Relationen bestimmen auch den inhaltlichen Umfang der abzugebenden Daten für den einzelnen Nutzer; diese Angaben sind ebenfalls im Nutzerprofil, das z.B. in ALKIS durch die Objektart AX_Benutzergruppe realisiert ist, zu hinterlegen.

Das NBA-Verfahren ist für alle Objektarten anzubieten, die eine datenführende Stelle im Bestand führt, ausgenommen Objekte mit dem Stereotype und dem Tagged Value "retired". Für den Nutzer kann die Selektion auf dem gesamten Vorrat der Objekteigenschaften aufsetzen; die Anforderungen des Datenschutzes sind dabei jedoch zu berücksichtigen. Als Ergebnis liefert das NBA-Verfahren als kleinste Einheiten der Änderungsdaten immer Fachobjekte. Werden Fortführungsdaten für dasselbe Zeitintervall in mehreren Portionen an Nutzer abgegeben, stellt das abgebende System sicher, dass dieselbe Version eines Fachobjektes nur einmal an den Nutzer abgegeben wird.

Diese Daten sind vollständig in Bezug auf das aktuelle Nutzerprofil; aus Sicht des gesamten Datenbestandes können diese Objekte unvollständig sein. Sofern der Nutzer seine Selektion auf einzelne Objekteigenschaften beschränkt (Nutzerprofil), können zwischen den Lieferungen Inkonsistenzen zwischen dem vorhandenen Datenbestand beim Nutzer und der aktuellen Datenhaltung in der datenführenden Stelle auftreten. Dies kann passieren durch die Aktualisierung der Bestandsdaten im Bereich der Selektionskriterien oder Änderungen der Selektionskriterien. Derartige Inkonsistenzen müssen vom aufnehmenden System gehandhabt werden.

Die räumliche Ausdehnung des Interessengebiets eines Nutzers wird durch Angabe beliebiger Flächen (Flächenobjekte) im Nutzerprofil beschrieben. Raumbezogene Elementarobjekte (REO) qualifizieren sich, sobald die Geometrie eines Objekts durch die Geometrie des Interessengebietes angeschnitten wird (Operation INTERSECTS) oder die Geometrie des Objektes vollständig im Interessensgebiet liegt.

Vor der ersten Datenabgabe ist das Nutzerprofil (AX_Benutzergruppe) mit den fachlichen, räumlichen und zeitlichen Kriterien für die NBA-Änderungsdaten zu erstellen. Die fachlichen und räumlichen Kriterien können auch im Nachhinein verändert werden.

Technisch soll die Änderung von Selektionskriterien einer NBA stets durch einen Fortführungsauftrag der Verarbeitungsart 4000 (Fortführen ohne Sperre) abgewickelt werden, der die Objektarten AX_BenutzergruppeNBA und ggf. AX_Benutzer umfasst. Dabei sind Fortführungen während laufenden NBA-Prozessen unzulässig.

Aus Sicht des NBA-Beziehers müssen alle Objekte und mit ihnen in relationalem und attributivem [sprich: schlüsselseitigem] Zusammenhang stehenden weiteren Objekte, die in das Gebiet der Erweiterung ganz oder teilweise fallen, wie bei einer NBA-Erstabgabe behandelt werden. Gleiches gilt auch für fachliche Erweiterungen innerhalb eines NBA-Gebietes. Das heißt, dass die zum bisherigen NBA-Gebiet gehörige Datenabgabe sich um Einfüge-Operationen für die erstmalig abzugebenden Objekte vergrößert. Erweiterungen und Wieder- bzw. Aufholungsläufe schließen sich aus. Für NBA-Bezieher sollen in Zusammenhang mit räumlichen und fachlichen Reduzierungen keine Löschsätze erzeugt werden. Änderungen zu den nicht mehr räumlich bzw. fachlich inbegriffenen Objekten werden ab der Reduzierung einfach nicht mehr geliefert. Zeitliche Erweiterungen (zusätzliche Abgabe von historischen Versionen) und Reduzierungen sind nicht vorgesehen.

In welchem Umfang Objekte durch Nachverfolgung von Relationen nachzuziehen sind, muss ebenfalls in den Selektionskriterien des Nutzerprofils beschrieben sein.

Der Zeitraum, für den die Bereitstellung von Änderungsdaten nach dem Verfahren NBA für verschiedene Nutzer sichergestellt werden muss, kann zeitlich begrenzt werden (zeitlicher Rahmen). Damit wird es möglich,

Das Verfahren zur Nutzerbezogenen Bestandsdatenaktualisierung erfordert, dass für diesen Zeitraum Informationen über die Veränderung des Datenbestandes vorgehalten werden. Der Zeitraum wird durch die datenführende Stelle in Abstimmung mit den Nutzern bestimmt.

Die beim Verfahren NBA erforderliche Verwaltung der verschiedenen Ausprägungen eines Objektes über die Zeit wird durch das Versionskonzept abgedeckt. Deshalb wird

Damit ist es möglich,

durchzuführen.

Um eindeutig die zu überschreibende Version zu kennzeichnen und Übermittlungsfehler im NBA-Verfahren aufzudecken, ist es erforderlich, den Objektidentifikator beim Datenaustausch um das Entstehungsdatum/-zeit zu ergänzen. Dies erfordert folgende Regeln:

Für die Ableitung der zu erzeugenden Fortführungsoperationen ist auszuwerten, ob das sich für die Datenausgabe qualifizierende Objekt aus Sicht der Datenhaltung eine erste, weitere oder letzte Version ist.

Bei Verfolgung von inversen Relationen kann <wfs:PropertyName> bzw. <wfsext:PropertyName> mit dem Attribut resolve="local" kein Lebenszeitintervall bei Selektionskriterien für die NBA-Abgabe transportieren. Das hat zur Folge, dass eine oder mehrere Objektversion(en) als Ergebnis geliefert werden. Für die korrekte zeitliche Zuordnung sind weitere Bearbeitungsschritte erforderlich, die durch die Software-Implementierungen sicherzustellen sind.

Die Portionierung von NBA-Daten ist optional. Es besteht kein Zwang, diese zu verwenden, sie erlaubt jedoch den NBA-Beziehern die Übernahme der Daten in Etappen, was sich in der Vergangenheit bezüglich der Altverfahren insbesondere bei umfangreichen Datenbeständen bewährt hat.

Es werden insbesondere die folgenden Anforderungen adressiert: Bereitstellung der Daten von ALKIS und von ATKIS in geometrischer Portionierung. Die Portionsgröße soll variabel, aber einheitlich für einen Bezieher (Parametrisierung der Portionsgröße im Benutzerprofil) sein. NREO und ZUSO werden portionsbezogen über Relationen gemäß Selektionskriterien im Nutzerprofil nachgezogen. Eine Portionierung allein nach Datenmenge ist nicht ausreichend.

Die Datenabgabe an Sekundärnutzer soll möglichst "vollautomatisch" für das abgebende System und das aufnehmende System sein. Hierfür wird das Attribut <profilkennung> verwendet.

Bei der unportionierten Ausgabe war die Ausgabe der Profilkennung früher nicht verpflichtend. Diese Attributart wurde daher als Pflichtattribut bei AX_NutzerbezogeneBestandsdatenaktualisierungNBA ergänzt. Damit wird nicht zwischen der portionierten und unportionierten Ausgabe durch Weglassen der Attributart <portionskennung> unterschieden, sondern durch die Angaben in <laufendeNummerVonGesamtzahl> und <gesamtzahl> im Datentyp AX_Portionskennung. Im Falle der unportionierten Abgabe sind beide Werte mit "1" belegt.

Portion ohne Raumbezug

Vor der Portionierung müssen über einen Benutzungsauftrag alle Objekte und mit ihnen in relationalem und attributivem Zusammenhang stehenden weiteren Objekte (ZUSO, NREO, REO) über die Selektionskriterien aus der DHK selektiert worden sein. Diese selektierte Menge an Objekten kann dann ggf. portioniert werden, entweder mit Hilfe von geometrischen Parametern oder ohne. Die Portionierung zieht keine weiteren (ggf. fehlende) Objekte nach.

Dazu kann die Attributart AX_Portionskennung.suedwestEcke mit einem der Portionierungskonvention konformen Wert belegt werden oder unbelegt bleiben. Der Dateiname enthält je nachdem den o.g. konformen Wert oder der Dateinamensanteil von suedwestEcke wird nicht belegt. Die Position der nicht-raumbezogenen Portionen in der Portionsfolge ist frei wählbar.

Protokolldatei

Mit einer Portionsfolge bzw. einer unportionierten Gesamtlieferung kann eine optionale Protokolldatei mit Erläuterungen geliefert werden.

Im Falle der Portionierung ist diese als erste Portion einer Portionsfolge mit der laufenden Nummer 0 anzugeben. Im Falle der unportionierten Gesamtlieferung soll der Zusammenhang der Protokolldatei mit der NBA-Lieferung durch deren Dateinamen zum Ausdruck kommen, indem der Name der Protokolldatei gleich dem Namen der NBA-Lieferung ergänzt um "_p" am Ende, gefolgt vom Punkt mit Dateiextension (i.d.R. ".xml", ggf. auch "zip" usw.) sein soll. Ansonsten gelten für die Protokolldatei die Regeln einer Portionsdatei ohne Raumbezug (siehe oben TBD: Genaue Referenz?).

Bei Übernahme einer NBA-Lieferung kann eine Quittierung an die liefernde Stelle in Form des NBA-Quittierungs-Auftrags AX_NBAQuittierung erfolgen, soweit dies länderspezifisch gewünscht wird und in der NBA-Lieferung angefordert wurde. Die Art der Verarbeitung der NBA-Quittierung obliegt länderspezifischen Regelungen.

Eine Codeliste definiert einen Wertebereich, in dem für jeden zulässigen Wert ein Code zugeordnet wird (ISO 19136). Die Abgrenzung der Begriffe "Enumeration" und "CodeList" erfolgt gemäß ISO 19103:

Eine Enumeration ist eine abschließende Sammlung von zulässigen Werten mit dem Stereotyp «enumeration» versehen. Enumerationen können nicht erweitert werden.

Eine Codelist ist eine nicht abschließende Sammlung von zulässigen Werten mit dem Stereotyp «codeList» versehen. Codelisten können erweitert werden.

ISO 19103 unterscheidet zwei Arten von Codelisten: Solche mit dem Tagged Value "codeList" (diese werden von einer einzigen zuständigen Stelle geführt) und solche ohne diesen Tagged Value (diese können beliebig von jedem Benutzer des zugehörigen Anwendungsschemas erweitert werden).

Im Basisschema gebrauchte Code-Listen, die von ihrem Charakter her a) von den anwendungsspezifischen Subschemata gefüllt werden müssen und b) zur Integration unterschiedlicher Anwendungen erweiterbar sein müssen, werden im Basisschema in der Regel als leere Klassen definiert und mit dem Stereotype «CodeList» versehen. In einigen Fällen sind bei Codelisten im Basisschema Wertearten angegeben (z.B. bei AA_Anlassart). Erweiterungen und Änderungen dieser Listen führen nicht zu einer neuen Version der Austauschschnittstelle. Sie erscheinen demnach nicht im Ausgabe-Schema, sondern werden in Form eines dictionaries in einer "externen" XML-Datei geführt. Sie werden an zentraler Stelle mit der Möglichkeit des online-Zugriffs geführt und gepflegt. Mit den Implementierungen des AAA-Modells wächst der Bedarf für ein Konzept zur Erweiterung dieser Codelisten. Hat sich z.B. Land XYZ im Sinne des AdV-Leitfadens zur Fachdatenanbindung eine länderspezifische Ausgabe geschaffen, so fehlt noch ein Code in der Codelist AX_Anlassart_Benutzungsauftrag, um die Erzeugung eben dieser Ausgabe initiieren zu können.

Alle Codelisten des AAA-Fachschemas führen vier- oder sechsstellige Ganzzahl-Codes (wegen führenden Nullen ungleich Integer). Für eine länderspezifische Erweiterung kommen folgende Codelisten mit folgender Stellenzahl in Frage:

Die länderspezifische Erweiterung von Codelisten des AAA-Fachschemas (hier speziell der Codes) wird mit dem zweistelligen Länderkürzel (vgl. Abschnitt 3.3.9, “Identifikatoren, Verknüpfungen”) eingeleitet. Dem BKG steht das dort vorgesehene dreistellige Kürzel "BKG" zur Verfügung.

Als weitere Zeichen sind die Ziffern {0-9} und Zeichen {A-Z, a-z, ohne Umlaute} zulässig. Groß- und Kleinschreibung wird unterschieden.

Die Stellenanzahl des länderspezifischen Codes einschließlich Präfix sollte zur Erleichterung der Implementierung mit der des AdV-Codes identisch sein. Zukünftig könnte bei Fachinformationssystemen ggf. Bedarf an einer größeren Stellenzahl bestehen.

Beispiele:

Hierdurch vereinfacht sich eine zentrale Registrierung ("Registry") der erweiterbaren Codelisten (jedes Land und das BKG arbeitet im eigenen Namensraum). Falls die erwähnte Registrierung im Rahmen von GDI-DE nicht benötigt wird, kann sie sogar komplett entfallen.

Die Codelisten- und Enumerationswertearten mit Stereotype und Tagged Value "retired" führen diesen Status mit den zugehörigen Informationen ("gueltigVonModellversion", "gueltigBisModellversion") auch in der CER.

Eine weitere Anforderung zur Führung einer CER ergibt sich aus Abschnitt 3.6, “Qualitäts- und Metadaten”:

"In der Rollenangabe ist ein Codelistenverweis erforderlich, der gemäß ISO/TS 19139 8.5.5 eine URL sein muss. Im Beispiel ist eine URL auf ein Code-List-Dictionary im OGC-Schemarepository angegeben. Dies kann alternativ - wie bei Schemaverweisen - auch ein anderer gültiger Verweis auf ein Code-List-Dictionary sein."

Dies wird mit einem Beispiel näher illustriert:

Codelisten und Enumerationen der AdV werden in dem Codelisten-Register der GDI geführt (Link: GDI-DE Registry). Dies betrifft derzeit die Codelisten und Enumerationen aus dem AAA-Anwendungsschema und den Anwendungsschemata Landbedeckung, Landnutzung, Geometrische Verbesserung und Bodenrichtwertmodell. Die Vorgehensweise ist hierbei wie folgt:

In AFIS-ALKIS-ATKIS kann für jede Geometrie das zugehörige Koordinatenreferenzsystem (CRS) angegeben bzw. gespeichert werden. In diesem Abschnitt werden die dafür verwendeten (Kurz-) Bezeichnungen definiert.

Die Kurzbezeichnung setzt sich aus den folgenden Informationen zusammen:

{Land}_{geodätisches Datum}_{Koordinatensystem}_{Submerkmale des Koordinatenreferenzsystems (z.B.Lagestatus)}

Die zu benutzenden Kurzbezeichnungen werden in den weiter unten folgenden Tabellen festgelegt.

Vorbemerkungen: